今日目標，解釋 MVC 架構的詳細分層，並解釋我們之後開發架構。

分層

在前幾天，小弟僅介紹了 MVC 的基本架構以及其大致功用，今天要來解釋其內部更細的分層，並說明其功用。

• M
  • Model Layer：亦可稱為 Entity Layer，負責映射到資料表的結構(schema)
  • Repository Layer：亦可稱為 DAO(Data Access Object) Layer，負責封裝資料存取的方法
• V
  • 這部分通常不分層，resources 資料夾底下都屬於該層
• C
  • Service Layer：雖然中文直翻是服務層，但一般會說是「業務邏輯層」，業務邏輯層負責定義規則、工作流等，例如：收到資料後進行檢驗、決定資料如何被操作和處理
  • Controller Layer：將使用者的請求(request)做處理，並給予回應(response)，中間的資料操作、檢驗，通常透過 service layer 提供的方法來處理

Package by Layer vs Package by Feature

在開發上，有兩種建立 package 的習慣，一種是根據上方提到的分層(layer)來建立 package：

├─com.example
    ├─controller
    │   ├─CompanyController
    │   ├─OrderController
    │   └─UserController
    ├─model
    │   ├─CompanyModel
    │   ├─OrderModel
    │   └─UserModel
    ├─repository
    │   ├─CompanyRepository
    │   ├─OrderRepository
    │   └─UserRepository
    └─service
        ├─CompanyService
        ├─OrderService
        └─UserService

另一種則是根據功能(feature)來建立 package：

├─com.example
    ├─company
    │   ├─CompanyController
    │   ├─CompanyModel
    │   ├─CompanyRepository
    │   └─CompanyService
    ├─order
    │   ├─OrderController
    │   ├─OrderModel
    │   ├─OrderRepository
    │   └─OrderService
    └─user
        ├─UserController
        ├─UserModel
        ├─UserRepository
        └─UserService

在官方文件中，比較推薦的是後者，除此之外，我們可以進一步分析為什麼後者比較好。

I felt like I had to understand everything in order to help with anything. (我覺得我必須要了解一切才能解決任何問題) — Sandi Metz

在 package by layer 中，package 跟 package 之間的 內聚性[1] 低，但 耦合性[2] 高，這對於日後維護都是極度不方便，如同 Sandi Metz 說的，我必須知道一切(所有的 package 以及程式之間如何相依)，我才有辦法解決問題。

此外，我們如果以 package by feature，我們就不必都用 public 做修飾，可以用 package-private 來增加封裝性。

根據以上分析，小弟在本次文章中將會使用 Package by Feature。

名詞解釋

• [1] 內聚(Cohesion)：把所有相關的東西都塞在一個模組(package, class, function, etc.)，使其跟其他模組完全不相關，他自己能獨立運作
• [2] 耦合(Coupling)：跟內聚相反，模組跟模組之間互相依賴(例如：參數傳遞上)，他沒辦法獨自運作